The present invention generally relates to telecommunications and, more particularly, to feature interaction in the AIN (Advanced Intelligent Network) Framework.
Telecommunications software continues to evolve and add features. For example, in a telephone network, a feature is an add-on functionality to standard telephone service (e.g., call forwarding). The correct operation of a feature depends on a number of assumptions about its execution environment and available resources. Individual features are usually developed in isolation from each other and/or over a long period of time. When a set of features is put together, they might compete for limited system resources, and some of the underlying assumptions of a feature might be invalidated because of the execution of other features. As a result, a set of features might interfere with one another and exhibit unexpected and/or undesirable behaviors. This is the well-known "feature interaction" problem in telecommunications software engineering, which is further described in "The Feature Interaction Problem in Telecommunication Systems" by Bowen, T. F. et al., In Proceedings of the 7.sup.th International Conference on Software Engineering for Telecommunication Switching Systems, pp. 59-62, July 1989.
It is important to detect and resolve interactions among features before they are packaged for commercial offerings. Revenues are at stake if customers are baffled by the unexpected behavior of the set of features they subscribe to from a service provider. However, detecting and resolving interactions among features is a very difficult task. First, the logic of some of the features can be very complicated: it is not unusual for the documentation of a complex feature to run close to a hundred pages. Extracting the right amount of information from a document for interaction analysis requires a keen insight into feature design. Second, it is not unusual for a switching system to have hundreds of features. In addition, pairwise feature interaction analysis is not sufficient to uncover all the interactions among a set of features. As a result, even if one has access to all the information on the features developed for one's own products, one has to deal potentially with an exponential number of cases in the analysis.
The feature interaction problem has become even more complicated with the advent of the Advanced Intelligent Network (AIN) and the government deregulation in the telecommunications industry. In the AIN architecture, service logic can be stored at a Service Control Point (SCP), while the switching functions are provided in the Service Switching Point (SSP). The SSP is further described in TR-NWT001284: "Advanced Intelligent Network (AIN) Switching Systems Generic Requiremeits (Release 0.1)" by Bellcore, August 1992. Similarly, the SCP is a computing system containing processing logic and is further described in TR-NWT001285: "Advanced Intelligent Network (AIN) 0.1 Switch-Service Control Point (SCP) Application Protocol Interface Generic Requirements" by Bellcore, August 1992. In addition, AIN provides a set of well-defined interfaces between the SSP and the SCP to allow service logic programs in the SCP to be invoked by the SSP and to influence call processing in the SSP. The separation of service logic fiom switching functions allows service providers to develop features independent of switch vendors.
The passing of the Telecommunications Act of 1996 requires Incumbent Local Exchange Carriers (ILECs) to unbundle "dial tones" to third party service providers (i.e. other Competing LECs or CLECs). The unbundling of ILECs' networks can create the scenario in which ILECs may have to provide mediated access to features developed by third party service providers due to future FCC or state mandates. In this context, features can be classified into two categories: (1) "switch-based features," which usually come from the switch vendors and reside on the switches; and (2) "AIN features," which are usually developed by operating phone companies and third party service providers. Due to competition among third party service providers and between third party service providers and operating phone companies, only limited input/output behaviors are publicly available for each feature. Consequently, the operating phone companies face the challenge of providing mediated access for third party features without knowing the internal logic of these features.
Feature Interaction Problem in AIN Release 0.1
FIG. 1 shows two service SSPs 102 in an AIN 0.1 environment. The SSPs 102 are connected across a network 106 that may contain other SSPs switching points and various nodes between the end points. The SSPs 102 shown in the figure are also each connected to a SCP 104.
At the heart of AIN is the "basic call model" (BCM), which is a finite state machine residing on an SSP 102 that models the progress of a call. For a typical call, there is an "originating" basic call model (OBCM) 108 at the SSP 102 of the caller side 112 and a "terminating" basic call model (TBCM) at the SSP 102 of the callee side 114.
FIGS. 2a and 2b show graphical representations of the OBCM 108 and TBCM 110, respectively. The BCMs shown in the FIGS. 2a and 2b are standard for AIN Release 0.1. Each basic call model defines a set of "points in call" (PICs) which correspond to the important states in a call. Associated with each PIC is a set of "detection points" (DPs) which are used to detect an event during a call. A DP is associated with a set of "triggers" each of which specifies the conditions under which an AIN feature can be invoked.
AIN features are implemented by service logic programs residing on the SCP 104. Each AIN feature is associated with a set of triggers that specify at which PICs in the basic call model and under what conditions the feature can be invoked by the SSP 102 during a call. Typically, an AIN feature is invoked during a call if the following four conditions are satisfied: (1) the user has subscribed to this feature; (2) the user has activated this feature; (3) the call is at a PIC that the trigger of this feature is associated with; (4) the trigger condition is true. Note that even though an AIN feature, in general, can have more than one trigger, it can only be activated by one trigger at any instance during a call. In the following description, AIN features associated with a single trigger are considered, but the analysis extends to multiple triggers as well.
FIG. 3 shows a conceptual model of feature interaction in AIN Release 0.1. AIN is based on the SS7 Signaling Network Architecture, which is further described in Beninger, Toni, "SS7 Basics," Telephony Div. Intertec Publishing Corp. ISBN:0-917845-16-1. The SSP 102 communicates with the SCP 104 via TCAP messages 302. TCAP (Transaction Capabilities Application Part) is an SS7 application protocol which provides non-circuit related information transfer capabilities and generic services to applications, yet remains independent of the application. For feature interaction detection, the focus is on call-related TCAP messages 302, i.e., those that affect the processing of a call. Each TCAP message 302 carries a set of call variables (as TCAP parameters), which are used to exchange call-related information between an SSP 102 and an SCP 104. When an AIN feature 304 is invoked, the SSP 102 sends a query message with a set of call variable values to the SCP 104 to start the execution of the feature on the SCP 104. Upon the receipt of the query message, the SCP 104 executes the service logic program according to the type of message and the call variable values in the message. The SCP 104 then informs the SSP 102 of the next action to take by sending a response message back the SSP with a set of call variables whose values may have been generated or modified by the SCP. The SSP 102 uses these call variable values received in the response message to influence the call processing. There might be several rounds of message exchanges between the SSP 102 and the SCP 104 before the feature 304 is done. In summary, an invocation of an AIN feature 304 can be regarded as a transaction between an SSP 102 and an SCP 104, which starts with a query message from the SSP and involves a finite sequence of message exchanges between the SSP and the SCP. Switch-based features 306 are described below.
The execution of an AIN feature is atomic with respect to other AIN features, i.e., once an AIN feature is invoked, it cannot be interrupted by another AIN feature until it is finished. In AIN Release 0.1, the same holds true for AIN and switch-based features, an AIN feature cannot be interrupted by a switch-based feature and vice-versa.
It is possible for an AIN 0.1 feature to cause a modification in the control flow of the call model within which it is activated. Thus, it is possible that the AIN feature may start out at one PIC and terminate at another. In one embodiment consistent with the present invention, those features that terminate at the same PIC as the one at which they triggered are considered.
There are two major reasons why features interact with each other: "control sharing" and "data sharing". For control sharing, a set of features share the state information of the same basic call model, and consequently, the order of invocation among the features is very important. If one feature disconnects the call, then all the remaining features will not be able to execute. This is called "disabling."
For data sharing, features share the same set of call variables on a SSP 102 for call processing (see FIG. 3). Since the set of call variables carried in the TCAP messages 302 between the SSP 102 and the SCP 104 is essential to allow a feature 304 to influence call processing in the SSP, call variable values set or changed by one feature 304 might affect other features invoked later in the same basic call model that read and use these call variables. This is called a "side-effect."
Accordingly, it would be desirable to have a system that quickly and efficiently recognizes these problems and determines whether a feature package has potential interactions.